home *** CD-ROM | disk | FTP | other *** search
/ Danny Amor's Online Library / Danny Amor's Online Library - Volume 1.iso / bbs / rfc / rfcxxxx_8.lha / rfc1761 < prev    next >
Text File  |  1995-07-26  |  11KB  |  340 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                       B. Callaghan
  8. Request for Comments: 1761                                   R. Gilligan
  9. Category: Informational                           Sun Microsystems, Inc.
  10.                                                            February 1995
  11.  
  12.  
  13.                Snoop Version 2 Packet Capture File Format
  14.  
  15. Status of this Memo
  16.  
  17.    This memo provides information for the Internet community.  This memo
  18.    does not specify an Internet standard of any kind.  Distribution of
  19.    this memo is unlimited.
  20.  
  21. Abstract
  22.  
  23.    This paper describes the file format used by "snoop", a packet
  24.    monitoring and capture program developed by Sun.  This paper is
  25.    provided so that people can write compatible programs to generate and
  26.    interpret snoop packet capture files.
  27.  
  28. 1.  Introduction
  29.  
  30.    The availability of tools to capture, display and interpret packets
  31.    traversing a network has proven extremely useful in debugging
  32.    networking problems.  The ability to capture packets and store them
  33.    for later analysis allows one to de-couple the tasks of collecting
  34.    information about a network problem and analysing that information.
  35.    The "snoop" program, developed by Sun, has the ability to capture
  36.    packets and store them in a file, and can interpret the packets
  37.    stored in capture files.  This RFC describes the file format that the
  38.    snoop program uses to store captured packets.  This paper was written
  39.    so that others may write programs to interpret the capture files
  40.    generated by snoop, or create capture files that can be interpreted
  41.    by snoop.
  42.  
  43.  
  44.  
  45.  
  46.  
  47.  
  48.  
  49.  
  50.  
  51.  
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58. Callaghan & Gilligan                                            [Page 1]
  59.  
  60. RFC 1761            Snoop Packet Capture File Format       February 1995
  61.  
  62.  
  63. 2.  File Format
  64.  
  65.    The snoop packet capture file is an array of octets structured as
  66.    follows:
  67.  
  68.         +------------------------+
  69.         |                        |
  70.         |      File Header       |
  71.         |                        |
  72.         +------------------------+
  73.         |                        |
  74.         |     Packet Record      |
  75.         ~        Number 1        ~
  76.         |                        |
  77.         +------------------------+
  78.         .                        .
  79.         .                        .
  80.         .                        .
  81.         +------------------------+
  82.         |                        |
  83.         |     Packet Record      |
  84.         ~        Number N        ~
  85.         |                        |
  86.         +------------------------+
  87.  
  88.    The File Header is a fixed-length field containing general
  89.    information about the packet file and the format of the packet
  90.    records it contains.  One or more variable-length Packet Record
  91.    fields follow the File Header field.  Each Packet Record field holds
  92.    the data of one captured packet.
  93.  
  94. 3. File Header
  95.  
  96.    The structure of the File Header is as follows:
  97.  
  98.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  99.     |                                                               |
  100.     +                     Identification Pattern                    +
  101.     |                                                               |
  102.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  103.     |                       Version Number = 2                      |
  104.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  105.     |                         Datalink Type                         |
  106.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  107.  
  108.  
  109.  
  110.  
  111.  
  112.  
  113.  
  114. Callaghan & Gilligan                                            [Page 2]
  115.  
  116. RFC 1761            Snoop Packet Capture File Format       February 1995
  117.  
  118.  
  119.         Identification Pattern:
  120.  
  121.                 A 64-bit (8 octet) pattern used to identify the file as
  122.                 a snoop packet capture file.  The Identification Pattern
  123.                 consists of the 8 hexadecimal octets:
  124.  
  125.                         73 6E 6F 6F 70 00 00 00
  126.  
  127.                 This is the ASCII string "snoop" followed by three null
  128.                 octets.
  129.  
  130.         Version Number:
  131.  
  132.                 A 32-bit (4 octet) unsigned integer value representing
  133.                 the version of the packet capture file being used.  This
  134.                 document describes version number 2.  (Version number 1
  135.                 was used in early implementations and is now obsolete.)
  136.  
  137.         Datalink Type:
  138.  
  139.                 A 32-bit (4 octet) field identifying the type of
  140.                 datalink header used in the packet records that follow.
  141.                 The datalink type codes are listed in the table below:
  142.  
  143.                 Datalink Type           Code
  144.                 -------------           ----
  145.                 IEEE 802.3              0
  146.                 IEEE 802.4 Token Bus    1
  147.                 IEEE 802.5 Token Ring   2
  148.                 IEEE 802.6 Metro Net    3
  149.                 Ethernet                4
  150.                 HDLC                    5
  151.                 Character Synchronous   6
  152.                 IBM Channel-to-Channel  7
  153.                 FDDI                    8
  154.                 Other                   9
  155.                 Unassigned              10 - 4294967295
  156.  
  157. 4. Packet Record Format
  158.  
  159.    Each packet record holds a partial or complete copy of one packet as
  160.    well as some descriptive information about that packet.  The packet
  161.    may be truncated in order to limit the amount of data to be stored in
  162.    the packet file.  In addition, the packet record may be padded in
  163.    order for it to align on a convenient machine-dependent boundary.
  164.    Each packet record holds 24 octets of descriptive information about
  165.    the packet, followed by the packet data, which is variable-length,
  166.    and an optional pad field.  The descriptive information is structured
  167.  
  168.  
  169.  
  170. Callaghan & Gilligan                                            [Page 3]
  171.  
  172. RFC 1761            Snoop Packet Capture File Format       February 1995
  173.  
  174.  
  175.    as six 32-bit (4-octet) integer values.
  176.  
  177.    The structure of the packet record is as follows:
  178.  
  179.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  180.     |                        Original Length                        |
  181.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  182.     |                        Included Length                        |
  183.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  184.     |                      Packet Record Length                     |
  185.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  186.     |                        Cumulative Drops                       |
  187.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  188.     |                       Timestamp Seconds                       |
  189.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  190.     |                     Timestamp Microseconds                    |
  191.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  192.     |                                                               |
  193.     .                                                               .
  194.     .                          Packet Data                          .
  195.     .                                                               .
  196.     +                                               +- - - - - - - -+
  197.     |                                               |     Pad       |
  198.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  199.  
  200.         Original Length
  201.  
  202.                 32-bit unsigned integer representing the length in
  203.                 octets of the captured packet as received via a network.
  204.  
  205.         Included Length
  206.  
  207.                 32-bit unsigned integer representing the length of the
  208.                 Packet Data field.  This is the number of octets of the
  209.                 captured packet that are included in this packet record.
  210.                 If the received packet was truncated, the Included
  211.                 Length field will be less than the Original Length
  212.                 field.
  213.  
  214.         Packet Record Length
  215.  
  216.                 32-bit unsigned integer representing the total length of
  217.                 this packet record in octets.  This includes the 24
  218.                 octets of descriptive information, the length of the
  219.                 Packet Data field, and the length of the Pad field.
  220.  
  221.  
  222.  
  223.  
  224.  
  225.  
  226. Callaghan & Gilligan                                            [Page 4]
  227.  
  228. RFC 1761            Snoop Packet Capture File Format       February 1995
  229.  
  230.  
  231.         Cumulative Drops
  232.  
  233.                 32-bit unsigned integer representing the number of
  234.                 packets that were lost by the system that created the
  235.                 packet file between the first packet record in the
  236.                 file and this one.  Packets may be lost because of
  237.                 insufficient resources in the capturing system, or for
  238.                 other reasons.  Note: some implementations lack the
  239.                 ability to count dropped packets.  Those
  240.                 implementations may set the cumulative drops value to
  241.                 zero.
  242.  
  243.         Timestamp Seconds
  244.  
  245.                 32-bit unsigned integer representing the time, in
  246.                 seconds since January 1, 1970, when the packet arrived.
  247.  
  248.         Timestamp Microseconds
  249.  
  250.                 32-bit unsigned integer representing microsecond
  251.                 resolution of packet arrival time.
  252.  
  253.         Packet Data
  254.  
  255.                 Variable-length field holding the packet that was
  256.                 captured, beginning with its datalink header.  The
  257.                 Datalink Type field of the file header can be used to
  258.                 determine how to decode the datalink header.  The length
  259.                 of the Packet Data field is given in the Included Length
  260.                 field.
  261.  
  262.         Pad
  263.  
  264.                 Variable-length field holding zero or more octets that
  265.                 pads the packet record out to a convenient boundary.
  266.  
  267. 5.  Data Format
  268.  
  269.    All integer values are stored in "big-endian" order, with the high-
  270.    order bits first.
  271.  
  272. 6.  Security Considerations
  273.  
  274.    Security issues are not discussed in this memo.
  275.  
  276.  
  277.  
  278.  
  279.  
  280.  
  281.  
  282. Callaghan & Gilligan                                            [Page 5]
  283.  
  284. RFC 1761            Snoop Packet Capture File Format       February 1995
  285.  
  286.  
  287. Authors' Addresses
  288.  
  289.    Brent Callaghan
  290.    Sun Microsystems, Inc.
  291.    2550 Garcia Avenue
  292.    Mailstop UMTV05-44
  293.    Mountain View, CA 94043-1100
  294.  
  295.    Phone: 1-415-336-1051
  296.    EMail: brent.callaghan@eng.sun.com
  297.  
  298.  
  299.    Robert E. Gilligan
  300.    Sun Microsystems, Inc.
  301.    2550 Garcia Avenue
  302.    Mailstop UMTV05-44
  303.    Mountain View, CA 94043-1100
  304.  
  305.    Phone: 1-415-336-1012
  306.    EMail: bob.gilligan@eng.sun.com
  307.  
  308.  
  309.  
  310.  
  311.  
  312.  
  313.  
  314.  
  315.  
  316.  
  317.  
  318.  
  319.  
  320.  
  321.  
  322.  
  323.  
  324.  
  325.  
  326.  
  327.  
  328.  
  329.  
  330.  
  331.  
  332.  
  333.  
  334.  
  335.  
  336.  
  337.  
  338. Callaghan & Gilligan                                            [Page 6]
  339.  
  340.